Ad IDs Behaving Badly

Published by Serge Egelman on February 14, 2019February 14, 2019

The Ad ID

Persistent identifiers are the bread and butter of the online tracking industry. They allow companies to learn the websites that you visit and the apps that you use, including what you do within those apps. A persistent identifier is just a unique number that is used to either identify you or your device. Your Social Security Number and phone number are examples of persistent identifiers used in real life; cookies use persistent identifiers to identify you across websites.

On your mobile device, there are many different types of persistent identifiers that are used by app developers and third parties contacted by those apps. For example, one app might send an advertising network your device’s serial number. When a different app on your same phone sends that same advertising network your device’s serial number, that advertising network now knows that you use both of these apps, and can use that information to profile you. This sort of profiling is what is meant by “behavioral advertising.” That is, they track your behaviors so that they can infer your interests from those behaviors, and then send you ads targeted to those inferred interests.

On the web, if you don’t want to be tracked in this manner, you can periodically clear your cookies or configure your browser to simply not accept cookies (though this breaks a lot of the web, given that there are many other uses for cookies beyond tracking). Clearing your cookies resets all of the persistent identifiers, which means that new persistent identifiers will be sent to third parties, making it more difficult for them to associate your future online activities with the previous profile they had constructed.

Regarding the persistent identifiers used by mobile apps, up until a few years ago, there was no way of doing the equivalent of clearing your cookies: many of the persistent identifiers used to track your mobile app activities were based in hardware, such the device’s serial number, IMEI, WiFi MAC address, SIM card serial number, etc. Many apps used (and still use) the Android ID for tracking purposes, which while not based in hardware, can only be reset by performing a factory reset on the device and deleting all of its data. Thus, there wasn’t an easy way for users to do the equivalent of clearing their cookies.

However, this changed in 2013 with the creation of the “ad ID”: both Android and iOS unveiled a new persistent identifier based in software that provides the user with privacy controls to reset that identifier at will (similar to clearing cookies).

Of course, being able to reset the ad identifier is only a good privacy-preserving solution if it is the only identifier being collected from the device. Imagine the following situation:

1. An app sends both the ad ID and the IMEI (a non-resettable hardware-based identifier) to a data broker.
2. Concerned with her privacy, the user uses one of the above privacy settings panels to reset her phone’s ad ID.
3. Later, when using a different app, the same data broker is sent the new ad ID alongside the IMEI.
4. The data broker sees that while the ad IDs are different between these two transmissions, the IMEI is the same, and therefore they must have come from the same device. Knowing this, the data broker can then add the second transmission to the user’s existing profile.

In this case, sending a non-resettable identifier alongside the ad ID completely undermines the privacy-preserving properties of the ad ID: resetting it does not prevent tracking. For this reason, both iOS and Android have policies that prohibit developers from transmitting other identifiers alongside the ad ID. For example, in 2017, it was major news that Uber’s app had violated iOS App Store privacy guidelines by collecting non-resettable persistent identifiers. Tim Cook personally threatened to have the Uber app removed from the store. Similarly, Google’s Play Store policy says that the ad ID cannot be transmitted alongside other identifiers without users’ explicit consent, and that for advertising purposes, the ad ID is the only identifier that can be used:

Association with personally-identifiable information or other identifiers. The advertising identifier must not be connected to personally-identifiable information or associated with any persistent device identifier (for example: SSAID, MAC address, IMEI, etc.) without explicit consent of the user.

…

Abiding by the terms of use. The advertising identifier may only be used in accordance with these terms, including by any party that you may share it with in the course of your business. All apps uploaded or published to Google Play must use the advertising ID (when available on a device) in lieu of any other device identifiers for any advertising purposes.

https://play.google.com/about/monetization-ads/ads/ad-id/

Violations of Ad ID Policies

I examined the AppCensus database to examine compliance with this policy. That is, are there apps violating this policy by transmitting the ad ID alongside other persistent identifiers to advertisers? When I performed this experiment last September, there were approximately 24k apps in our database that we had observed transmitting the ad ID. Of these, approximately 17k (i.e., ~70%) were transmitting the ad ID alongside other persistent identifiers. Based on the data recipients of some of the most popular offenders, these are clearly being used for advertising purposes:

This is just the top 20 most popular apps that are violating this policy, sorted alphabetically. All of the domains receiving the data in the right-most column are either advertising networks, or companies otherwise involved in tracking users’ interactions with ads (i.e., to use Google’s language, “any advertising purposes”). In fact, as of today, there are over 18k distinct apps transmitting the Ad ID alongside other persistent identifiers.

In September, our research group reported just under 17k apps to Google that were transmitting the ad ID alongside other identifiers. The data we gave them included the data types being transmitted and a list of the recipient domains, which included some of the following companies involved in mobile advertising:

• ad-mediation.tuanguwen.com
• ad.adsrvr.org
• ad.doubleclick.net
• ad.lkqd.net
• adc-ad-assets.adtilt.com
• admarvel-d.openx.net
• admediator.unityads.unity3d.com
• adproxy.fyber.com
• ads-roularta.adhese.com
• ads-secure.videohub.tv
• ads.adadapted.com
• ads.adecosystems.net
• ads.admarvel.com
• ads.api.vungle.com
• ads.flurry.com
• ads.heyzap.com
• ads.mopub.com
• ads.nexage.com
• ads.superawesome.tv
• adtrack.king.com
• adwatch.appodeal.com
• amazon-adsystem.com
• androidads23.adcolony.com
• api.salmonads.com
• app.adjust.com
• init.supersonicads.com
• live.chartboost.com
• marketing-ssl.upsight-api.com
• track.appsflyer.com
• ws.tapjoyads.com

The majority of these have the word “ads” in the hostname. Looking at the traffic shows that they are either being used to place ads in apps, or track user engagement with ads.

It has been 5 months since we submitted that report, and we have not received anything from Google about whether they plan to address this pervasive problem. In the interim, more apps now appear to be violating Google’s policy. The problem with all of this is that Google is providing users with privacy controls (see above image), but those privacy controls don’t actually do anything because they only control the ad ID, and we’ve shown that in the vast majority of cases, other persistent identifiers are being collected by apps in addition to the ad ID.